Processing of deal tickets

ABSTRACT

A deal feed system for passing deal tickets to back office systems comprises a deal feed contributor which receives tickets from trades on a plurality of trading systems on a plurality of trading floors, a database for storing the tickets, and a distributor for passing the tickets to back office systems. Virtual deal codes are defined to which a plurality of real deal codes map. The virtual deal codes to which a ticket relates is stored in a table with a reference to the stored ticket. A deal code table is updated with the range of the virtual deal code and the update transmitted to the bank office systems and to traders.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a National Stage filing under 35 U.S.C. §371 ofInternational Application No. PCT/GB2004/001339, filed on Mar. 29, 2004,which designated the United States and which was in the Englishlanguage, and claims priority benefit from U.S. Provisional ApplicationNo. 60/458,882, filed on Mar. 28, 2003.

FIELD OF THE INVENTION

This invention relates to the processing of deal tickets, produced bytrading systems, for example for sending to back office systems of banksand other financial institutions. It is specifically concerned with themanner in which the details of deals are communication to back officesystems.

BACKGROUND TO THE INVENTION

Financial institutions trade many different instruments using manydifferent trading systems. In addition, an institution may have manydifferent trading floors, sometimes located in different countries. Inthe context of the foreign exchange spot market (FX spot), traders usetwo main trading system providers, EBS (provided by EBS DealingResources Inc.) and Reuters (provided by Reuters plc). These two systemsoperate completely independently of each other and, when a trade iscompleted, produce deal tickets which are sent to the back officesystems of the counterparties to the deals. Deal tickets are proof thata deal has been entered into by two counterparties and are the meansused by the banks to settle with counterparties. Deal tickets also allowreconciliation in the event of any doubt or dispute over a trade. Thedeal ticket will include an identification of the parties and the dealcode: a combination of a bank identifier and a trading systemidentifier; together with details of the trades such as which partyacted as maker and taker, the buy/sell price, the currency and theamount. All counterparties trading on systems such as the Reuters andEBS systems mentioned above are allocated a four letter deal code. Thismay be a unique code for the bank, in the case of smaller institutions,or may identify a particular trading floor within a bank. The dealtickets further are required to identify the trading system to whichthey relate and are supplied over a physically separate feed for eachtrading system on each floor. The feed is in one of a number ofestablished formats. For example, feeds from a Reuters system are inReuters TOF (Ticket Output Feed) & TOF over 18 format, whereas EBS dealsare in ASI (Automated System Interface) format. A bank that trades inthe FX markets only using Reuters Dealing 3000 (combined anonymousmatching and direct dealing system) and EBS spot matching and EBS TraderDirect Dealing for its foreign exchange products will therefore requirethree separate deal feed lines for each trading floor. However, largebanks will have many trading floors and the back office systems willhave cabling for each trading system operated by each trading floorwhich may include systems trading many other products. The amount ofcabling required is extremely inconvenient and extremely expensive. Forexample, the Reuters TOF protocol requires a separate serial line foreach deal code/trading system combination. An attempt to reduce thecabling requirement at back offices has been made by OCL (OptionsComputers Limited) who provide a product under the trademark DealHub.DealHub is a physical interface which receives inputs from all tradingfloors and provides a single output to the back office systems. DealHubprovides separate servers for both EBS and Reuters Deals and canconcatenate multiple input feeds from each system into a single dataflow. The servers continuously monitor the data flow from the ReutersTOF and EBS ASI feeds respectively and convert the raw data into datarecords suitable for trader and back office applications. The DealHubsystem is useful for reducing the amount of physical cabling required toprovide deal related data to back office systems. However, it stillrequires inputs from all the trading systems operated by all the tradingfloors of a bank and considerable investment in DealHub hardware andsoftware.

The present invention aims to simplify greatly the provision of dealtickets from trading systems to back office systems. In its broadestform, the invention provides a single deal code for all systems operatedby all trading floors of an institution. This code is a virtual dealcode to which all real trading floor/trading system codes are attachedas children. It can be processed on a single line eliminating the needfor separate cabling for each trading floor deal code/trading systemcombination.

Embodiments of the invention have the advantage that the need forindividual cabling from each system operated by each trading floor isavoided. Alternatively, the need for an interface accepting inputs fromeach trading system on each trading floor, as discussed above, isavoided. Embodiments of the invention greatly simplify the provision ofdeal tickets to back office systems and so greatly reduce the costs tofinancial institutions and to trading system providers.

Embodiments of the invention also have the advantage that clients canreceive a single range of sequence numbers for deal tickets fromdifferent trading systems and or deal codes. This avoids the need forreconciliation by back office systems.

More specifically, the invention provides a method of distributing dealinformation relating to trades conducted by trading floors on tradingsystems, each trading floor having a deal code unique to the floor andthe system on which the trade is made, the method comprising: defining avirtual deal code to which deal codes of a plurality of trading floorsand/or trading systems map, the virtual deal code having an associateddeal range.

The invention also provides a system for transmission of dealinformation relating to trades conducted by trading floors on tradingsystems to back office systems, wherein deal information is passed fromthe trading system to a deal feed system, the deal feed systemcomprising means for defining virtual deal codes to which deal codes ofa plurality of trading floors and/or trading systems map, the virtualdeal codes each having an associated deal range.

Preferably deal information is transmitted to a virtual deal code withinthe deal range of that virtual deal code.

Preferably, deal tickets are received from a trading system at thecontributor of a deal feed system. The deal tickets include a deal codewhich identifies the sending trading floor and the trading system onwhich the deal was conducted. A virtual deal code which maps on to thedeal code of the received deal ticket is retrieved and the deal ticketis stored with a reference to the virtual deal code.

Preferably, the deal tickets are stored in a deal ticket table at adatabase. This database also includes a virtual deal ticket table and adeal code table. A reference to the deal ticket is stored in the virtualdeal ticket table with the virtual deal code, and the deal code table isupdated to be within the range of the virtual deal code. The updates tothe deal code table are distributed to back office systems under thevirtual deal codes. This may be via a single socket or serialconnection.

Preferably the virtual deal code is configured similarly to a real dealcode and includes a virtual trading system name and a virtual deal codename.

In one preferred embodiment of the invention a deal feed systemcomprises a contributor for receiving deal tickets, a distributor fordistribution of deal information to back office systems and a database.The database has a deal ticket table which stores the deal tickets, adeal code table referenced to the deal ticket table for storing the dealcode to which the ticket relates and a leg table for storing leginformation. Additionally a virtual deal ticket table stores a virtualdeal code with a reference to the ticket in the ticket table, togetherwith an RSN number within the range of the virtual deal code. The dealcode table for the ticket is updated so that the deal range is that ofthe virtual deal code. A virtual deal code is a label which references anumber of actual deal codes, each of which comprises a trading flooridentifier and a trading system identifier. When a deal ticket isreceived by the deal feed system, the system looks for a virtual dealcode to which that deal code maps.

Embodiments of the invention have the advantage that deal tickets from anumber of different trading systems on a number of different tradingfloors can be sent to back office systems via a single socket or serialconnection. This avoids the need for large numbers of parallelconnections required by prior art systems, making processing at the backoffice more simple and greatly reducing infrastructure costs.

Embodiments of the invention will now be described, by way of exampleonly, and with reference to the accompanying drawings in which:

FIG. 1 is a schematic representation of a virtual deal code and itsrelation to actual deal codes;

FIG. 2 shows, schematically, the relationship between a deal feed systemand a trading system;

FIG. 3 shows the deal feed client of FIG. 2 is more detail;

FIG. 4 is a schematic representation of a known deal feed system;

FIG. 5 shows, in more detail, the deal feed client and serverarchitecture;

FIG. 6 shows the operation of the deal feed contributor;

FIG. 7 shows the operation of the deal feed distributor; and

FIG. 8 is a schematic representation of the deal feed system of FIG. 5modified to embody the invention.

The invention contemplates the use of a super or virtual deal code whichencompasses all trading systems used by all trading systems of aninstitution. On the face of it, a simple solution to the problemaddressed would be to use a simple single adapter. However, thissolution is unable to provide a dynamic reproducible range that combinesseveral Trading System/Deal codes together. An adapter making such acombination into a single logical deal code must store the referenceoriginally presented to the back office systems so that the same ticketis returned if the client ever asks for it again. Thus, any simpleadapter that interfaces with a deal feed system will require anadditional database to store the references and the simple adapterbecomes an expensive resource. Clearly this is undesirable.

FIG. 1 illustrates a virtual deal code embodying the principles of theinvention. A virtual deal code is a super deal code that, logically,sits above all the real deal codes used by a bank's trading floors forall its trading systems. Thus, the virtual deal code is a label that isdefined along with a set of real trading system/deal codes. In FIG. 1the virtual deal code label is MyBankName/MYVIRDCI, 10 which representsa set of four real deal codes from two trading floors EBSA and EBSB.Each trading floor operates EBS trader™, the conversational EX tradingsystem operated by EBS, and EBS spot, the anonymous FX spot matchingsystem operated by EBS. Thus there are four codes, each comprising thesystem and the floor: EBSTrader/EBSA 12; EBSTrader/EBSB, 14; SPOT/EBSA16; and SPOT/EBSB 18.

FIG. 2 shows a schematic view of how a deal feed system communicateswith a trading system and customers. The trading system exchangeselectronic messages with trading system clients 42 in known manner via atrading system server 40, shown in this case as being via the Internet44. This is not necessarily the case. For example the EBS Trader®conversational dealing system communicates between clients 42 and server40 via the Internet, whereas the EBS spot matching system mentionedabove communicates via a dedicated communication network.

The exchange of messages between trading system clients 42 and server 40results in deals being completed.

Details of these deals, for example the parties, the deal amount,currency, settlement date etc. are passed by the trading system to thedeal feed system 46. In the embodiment shown, the system is aclient-server system with a central server 48 receiving completed tradedata from the trading system server and turning that data into dealtickets which it distributes to the appropriate deal feed clients 50 viathe Internet. Again, the system need not be Internet based. For anygiven deal there will be a maker and a taker and the deal ticket must besent to both parties. The deal feed clients send the received dealtickets to their back office systems for settlement. The tickets can beretrieved either from the local clients or the deal feed server in caseof any dispute as to the terms of a completed deal.

FIG. 3 shows the deal feed client in more detail. The client may be aconventional workstation typically running an operating system such asWindows NT®. It is connected to the Internet for communication with thedeal feed server 48 via a conventional network access connection 52 andhas output to a printer 54 for printing deal tickets, via a serial,parallel or USB cable; and to the back office system 56 using one of theTOF, ASI or TOF over IP protocols. Both TOF and ASI require a serialconnection 58 whereas TOF over IP requires a network connection to a hub60 and then a connection into the back office system 56. Both TOF overIP and TOF/ASI are shown in the Figures but it will be understood that agiven institution may not require all the variants.

FIG. 4 shows a conventional known deal feed system used to feed dealtickets from a trading system, in this case the EBS Trader system attrading floor EBSA. The system comprises three main components on boththe server and client sides: a deal feed Contributor 22 retrieves dealtickets, in this case from EBSTrader/EBSA. This may be performed on theclient or on the server via an input adapter. The deal feed contributormay retrieve deal tickets from a number of sources. The second componentis a deal feed Database 24 which stores deal feed tickets in a number oftables. A ticket table 26 holds the common ticket details; a leg table28 holds leg information; and a deal code table 30 holds the deal rangefor EBSTrader/EBSA and is incremented each time a deal ticket isretrieved from that code. The third component is a deal feed distributor32 that, on the server side, feeds deal feed tickets to the deal feedclients of the parties to the deal. Thus, a ticket is sent to EBSTrader/EBSA and to the counterparty to the trade the deal feeddistributor takes its input from the deal feed contributor 22 and thedeal feed database 24. On the client side the deal feed distributoroutput is the TDF/ASI or TOF over IP output and the printer output.

The mirroring of the architecture on the server and client sides isshown in FIG. 5.

The deal feed system provides storage and real-time notifications of newdeal tickets as follows. When a deal is performed, say atEBSTrader/EBSA, the contributor 22 retrieves the ticket either on theclient or the server. The deal is sent to the database 24 where commonticket details are written to the ticket table 26, leg information iswritten to the leg table 28 and the deal range for EBSTrader/EBSA isincremented in the Deal Code Table 30.

The Deal Feed Distributor is then informed of the updates to both theEBSTrader/EBSA and local deal ranges in real time and the dealdistributor 32 then informs any clients subscribed to EBSTrader/EBSA andlocally subscribed clients of the updates to the deal ranges.

This operation will now be described in more detail with reference toFIGS. 6 and 7 which show, respectively, how the deal feed contributorand distributor handle tickets. The deal feed contributor 22 connects toa client, which may be a trading system outputting deal tickets, or thedeal feed server sending tickets to a deal feed client. The client thencontributes tickets into the database, the contributor sends anacknowledgement response whereupon the client disconnects from thecontributor.

As shown in FIG. 6, at step 70, the contributor client sends acontribute ticket message to the deal feed contributor 22. At thecontributor, a contribution thread checks the message. At step 72, avalidated ContributeTicket message is placed on a contribution queue.The messages on this queue will include the trading system 10, dealcode, and originator ID as well as the ticket structure. At step 74 astorage thread takes tickets out of the contribution queue and at step76 attempts to store them in the database 24 via an interface. If theticket is stored successfully it will be allocated an RSN at step 78 or,if not, an error message will be returned. At step 80 the storageresults are placed on an acknowledgement queue and at step 82 a responsethread takes tickets from the acknowledgement queue and, if they have anRSN, at step 84, sends a contribution acknowledgement message back tothe ticket contributor.

FIG. 7 shows how the deal feed distributor retrieves tickets from thedeal feed database. At step 90, a getTicket message is sent to thedistributor. A request thread checks the message and, if validated, atstep 92 places the request message on a request queue. At step 94 aretrieval thread takes requests off the queue and attempts to retrievethe ticket from the database using an interface at step 96. If theticket is successfully retrieved it is added to a response queue. Ifnot, a blank queue is placed in the queue with an error message. At step98 the storage results are placed on the response queue and at step 100,a response thread takes tickets of the response queue and, at step 102,if they are not blank, returns a TicketInfo message to the client. Ifthey are blank, a ticket failure message is sent.

FIG. 8 shows how the known system is modified in accordance with anembodiment of the invention. FIG. 8 is a modification of FIG. 4. Thedeal feed database is modified to include a virtual deal code mappingsconfiguration 34. This is a storage device that stores a list of virtualdeal codes and the actual deal codes that map to that virtual deal code.Thus, the virtual deal code Local/MyVDC stores EBSTrader/EBSA,EBSTrader/EBSB, SPOT/EBSA and SPOT/EBSB as the mappings for that virtualdeal code. The database tables are supplemented by a virtual tickettable 36 which is written to whenever a ticket is received which is froma real deal code that maps to the virtual deal code.

The manner of operation of the modified system of FIG. 8 is similar tothat described with respect to the known deal feed system. In addition,when a deal ticket is received at the deal feed contributor 22, theorigin of that ticket, EBSTrader/EBSA is looked up in the Virtual DealCodes Configuration 34 to determine whether there is a virtual deal codeto which the actual deal code maps. If such a virtual deal code isfound, the deal, in addition to being written to the deal code, ticketand leg tables 26, 28 and 30 is also written to the virtual ticket table36. The entry at the virtual ticket table 36 will include the virtualtrading system name, for example ‘Local’ and the Virtual Deal Code Name,for example ‘MyVDC’. A reference to the ticket in the ticket table isalso included with an RSN number within the Local/MyVDC deal range andin the deal code table 30 the deal range for Local/MyVDC is updated. Inthe ticket table, only the reference to the virtual ticket table isstored. There is no need to store the actual ticket details a secondtime.

As additional deals are retrieved by the deal feed contributor they arestored against their base Trading System/Deal Code, that is their actualdeal code and are referenced against a virtual deal code in the virtualticket table if such a virtual deal code is detected in the virtual dealcode mappings configuration. Thus, if for example, the deal feedcontributor retrieves 10 deals from each of EBSTrader/EBSA, SPOT/EBSA,EBSTrader/EBSB and SPOT/EBSB deal codes, each in their separate dealranges, the Local/MyVDCI virtual deal code range would be indicating arange of 40 deals and the back office system which subscribes to theoutput of the deal feed distributor receives all 40 actual deal codedata on the Local/MyVCD output whilst perceiving a single deal code. Inthe case of the Reuters TOF protocol, the multiple deal codes areperceived as a single TCID.

Thus, in the system described, local deal feed outputs at each tradingsystem on each trading floor output deal data to the deal feedcontributor. As the system includes a mapping of actual deal codes tovirtual deal codes, the deal feed distributor can output the deal feeddata from a number of actual deal codes as a single virtual deal code.This enables a bank's back office to receive deal tickets from alltrading systems on all trading floors as a single input, removing theneed for large amounts of cablings used by the prior art requirement fora single feed for each deal code/trading system pair.

As the virtual deal codes described may be used in the context of anexisting deal feed system, virtual deal codes may be used with allexisting adapters. Thus, the embodiment described has the advantage ofbeing easy to implement with minimal additional expense.

Existing deal feed systems are client server systems with the clientsbeing located at banks' trading floors. Virtual deal code functionalitymay be included at both the deal feed client and the deal feed server.This provides complete flexibility as between the system provider andthe customer as to who manages the configuration of Virtual Deal Codes.The database on existing deal feed systems merely requiresreconfiguration to include a new field in the Deal Code table forreferencing to a new virtual ticket table. However, the actual dealticket is only stored once on the client and the server. The virtualdeal codes are no more than references to the existing ticket stored inthe database.

The configuration of virtual deal codes is very flexible enablingcustomers to change the mappings of actual deal codes onto a virtualdeal code. Thus, deal ranges can be added and removed. There is also nolimit to the number of Trading System/Deal Codes that can be created andmapped to a single virtual deal code. Banks may, if they choose, presentthe same set of information combined in any number of Virtual DealCodes.

The embodiment described allows banks to receive deals, and ifappropriate, associated conversations, from multiple trading systems anddeal codes using any of the systems adapters, such as TOF, ASI and TOFover IP through a single socket or serial connection, by using a singledeal code, irrespective of the trading system or the trading floor wherethe deal was done. The Deal Feed System only transmits one deal code andprovides a single ticket/RSN number to the client even though multipletrading systems and/or deal codes have been mapped to a single socket orserial connection.

Various modifications to the embodiment described are possible withinthe scope of the invention. For example, an institution may wish to setup a number of virtual deal codes, with each virtual deal coderepresenting a number of floors trading on a single system. Thus, afirst virtual deal code may represent all floors using an EBSconversational trading system and a second code for all trading floorsusing an EBS anonymous matching system.

The invention is not limited to the use of virtual deal codes within thespecific deal feed system described. The concept of virtual deal codesmay be implemented in a variety of different ways in various differenttypes of deal feed systems all of which are within the scope of theinvention.

1. A method of distributing deal information between computers on anetwork relating to trades conducted by trading floors on tradingsystems comprising computers on a network, each trading floor having adeal code unique to the floor and the trading system on which the tradeis made, the method comprising: a first computer or computers receivingdeal tickets from trading floors, each deal ticket relating to a tradeon a given trading system and including a trading floor identifier; thefirst computer or computers retrieving a virtual deal code to which dealcodes of a plurality of trading floors and trading systems map, thevirtual deal code having an associated deal range; the first computer orcomputers storing the received deal tickets with a reference to theretrieved virtual deal code; and the first computer or computersoutputting the deal tickets as a single virtual deal code to a secondcomputer or computers.
 2. The method according to claim 1, comprisingtransmitting deal information from the plurality of trading floors andtrading systems under the virtual deal code within the range of thevirtual deal code.
 3. The method according to claim 1, wherein the dealtickets are retrieved from the plurality of trading floors and tradingsystems and stored at a database, the method comprising storing the dealin a virtual deal ticket table.
 4. The method according to claim 3,wherein the deal ticket is stored in a deal ticket table and the virtualdeal code is stored in the virtual deal ticket table with a reference tothe ticket stored in the ticket table.
 5. The method according to claim4, wherein the database includes a deal code table for storing the dealcodes of received deal tickets with their deal ranges, comprisingupdating the deal range of stored deal codes to the deal range of thevirtual deal code.
 6. The method according to claim 5, wherein the dealinformation is distributed to a back office system for the virtual dealcode, comprising distributing deal range updates stored in the deal codetable to the virtual deal code.
 7. The method according to claim 6,wherein the updates distributed to the virtual deal code related to theplurality of trading floors and trading systems are distributed througha single socket or serial connection.
 8. The method according to claim1, wherein the virtual deal code comprises a virtual trading system nameand a virtual deal code name.
 9. The method according to claim 1,wherein a plurality of trading systems map onto the virtual deal code,wherein each trading system has a respective deal range within the dealrange of the virtual deal code.
 10. The method according to claim 1,wherein the deal information is provided as an electronic message. 11.The method according to claim 1, wherein the trading systems areelectronic trading systems.
 12. A method of distributing dealinformation between computers on a network relating to trades conductedby trading floors on trading systems comprising computers on a network,each trading floor having a deal code unique to the floor and thetrading system on which the trade is made, the method comprising: afirst computer or computers receiving deal tickets from trading floors,each deal ticket relating to a trade on a given trading system andincluding a trading floor identifier; the first computer or computersretrieving a virtual deal code to which deal codes of a plurality oftrading floors or trading systems map, the virtual deal code having anassociated deal range; the first computer or computers storing thereceived deal tickets with a reference to the retrieved virtual dealcode; and the first computer or computers outputting the deal tickets asa single virtual deal code to a second computer or computers.
 13. Themethod according to claim 12, comprising transmitting deal informationfrom the plurality of trading floors or trading systems under thevirtual deal code within the range of the virtual deal code.
 14. Themethod according to claim 12, wherein the deal tickets are retrievedfrom the plurality of trading floors or trading systems and stored at adatabase, the method comprising storing the deal in a virtual dealticket table.
 15. The method according to claim 14, wherein the dealticket is stored in a deal ticket table and the virtual deal code isstored in the virtual deal ticket table with a reference to the ticketstored in the ticket table.
 16. The method according to claim 15,wherein the database includes a deal code table for storing the dealcodes of received deal tickets with their deal ranges, comprisingupdating the deal range of stored deal codes to the deal range of thevirtual deal code.
 17. The method according to claim 16, wherein thedeal information is distributed to a back office system for the virtualdeal code, comprising distributing deal range updates stored in the dealcode table to the virtual deal code.
 18. The method according to claim17, wherein the updates distributed to the virtual deal code related tothe plurality of trading floors or trading systems are distributedthrough a single socket or serial connection.
 19. The method accordingto claim 12, wherein the virtual deal code comprises a virtual tradingsystem name and a virtual deal code name.
 20. The method according toclaim 12, wherein a plurality of trading systems map onto the virtualdeal code, wherein each trading system has a respective deal rangewithin the deal range of the virtual deal code.
 21. The method accordingto claim 12, wherein the deal information is provided as an electronicmessage.
 22. The method according to claim 12, wherein the tradingsystems are electronic trading systems.
 23. A system for distributingdeal information between computers on a network relating to tradesconducted by trading floors on trading systems comprising computers on anetwork, each trading floor having a deal code unique to the floor andthe trading system on which the trade is made, the system comprising: afirst computer or computers that: receives deal tickets from tradingfloors, each deal ticket relating to a trade on a given trading systemand including a trading floor identifier; retrieves a virtual deal codeto which deal codes of a plurality of trading floors and trading systemsmap, the virtual deal code having an associated deal range; stores thereceived deal tickets with a reference to the retrieved virtual dealcode; and outputs the deal tickets as a single virtual deal code to asecond computer or computers.
 24. A system for distributing dealinformation between computers on a network relating to trades conductedby trading floors on trading systems comprising computers on a network,each trading floor having a deal code unique to the floor and thetrading system on which the trade is made, the system comprising: afirst computer or computers that: receives deal tickets from tradingfloors, each deal ticket relating to a trade on a given trading systemand including a trading floor identifier; retrieves a virtual deal codeto which deal codes of a plurality of trading floors or trading systemsmap, the virtual deal code having an associated deal range; stores thereceived deal tickets with a reference to the retrieved virtual dealcode; and outputs the deal tickets as a single virtual deal code to asecond computer or computers.